<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="content-type"
 content="text/html; charset=ISO-8859-1">
  <title>Tasks</title>
</head>
<body>
<h1>Tasks</h1>
There are three types of task. As they are all tasks they are very
similar but are nevertheless intended for different purposes. The
similar features of all tasks are summarised in the following list:<br>
<ul>
  <li>Responsibility for a task can be assigned to a set of Contactable
entities (Organisation, Department or Person).</li>
  <li>A task is assigned an owner which defaults to but need not be the
creator of the task. It can be changed by a user with appropriate 
permission during editing.</li>
  <li>A task is assigned a Task Type which is used to determine work
flow. As a consequence, at any time, a task will have a current status
and state. The status effectively describes what has just happened to
the task and the state determines what is to be done next.</li>
  <li>Textual comments can be posted to a task and will appear in
chronological order in the Change Log.</li>
  <li>They can be searched in a hierarchical manner by means of several
different parameters. The most common search to perform is a check for
"My Tasks", all tasks in the current branch to whom the person logged
in is assigned responsibiliy.</li>
  <li>A task has an associated set of Contactable entities that will be
notified whenever the task is changed. Any user can toggle their
interested status in a task. A user with task editing permission may
make arbitrary changes to the set of interested Contactables. The
creator of a task has an option to be added to the interested set by
default. Finally, persons can be automatically assigned to the
interested set based on the interested roles of the task state machine.</li>
  <li>Tasks can be made dependent on or be a dependency of another task.</li>
  <li>Time spent by a Person can be logged to a Task and this forms the
basis of a very detailed timesheet recording mechanism.</li>
</ul>
The following list provides more detail on the differences between the
different task types. Essentially though, Projects and Actions will be
created during planning and Issues will be created during the execution
of the project and actions.<br>
<ol>
  <li><a href="projects/Projects.html"><span style="font-weight: bold;">Projects</span></a>
- A project is
expected to contain milestones and actions and is used primarily as a
management tool. It is meant to encapsulate the real world concept
of a project and will typically be used as a place holder in the tree.
Typically, the average user will not be given permission to create or
edit projects.<br>
  </li>
  <li><a href="actions/Actions.html"><span style="font-weight: bold;">Actions</span></a>
- An action is a
planning tool. It is used to represent some item of work that needs to
be performed as part of a project. It is expected that during planning,
the user will make a hierarchy of actions within a project node and set
up the necessary dependencies. Typically, the average user will not be
given permission to create or edit actions.</li>
  <li style="font-weight: bold;"><a href="issues/Issues.html">Issues</a><span
 style="font-weight: normal;"> - Issues are intended to be used as a
mechanism for indicating problems that have occurred during the
execution of a project plan. They are then used to track the activities
that need to be performed to correct the issue. This could involve
making modifications or additions to the project plan but will often be
quite self-contained. Note that the timing details associated with the
issues can be used to revise the timing of the project plan.</span></li>
</ol>
<h2>Posting Comments</h2>
If the user has permission then the "Post Comment" button will be
enabled at the bottom of any of the task types. Pressing this button
will bring up a form in which the user can type in a text comment.
Pressing OK will result in the comment being added to the change log of
the task. Alternatively, pressing Cancel will discard the comment.<br>
<h2>Changing State</h2>
If the user has permission then the "Change State" button will be
enabled at the bottom of any of the task types. Pressing this button
will bring up a form in which the user can select a transition to take
from the current state as well as space to enter a description or
comment regarding the state change. The list of available transitions
is based on the selected task type of the task as well as the current
state that the task is in and is presented in a combobox. It is also 
possible to generate an associated time sheet entry when changing state.
If the assign time checkbox is selected then the message will also be
assigned to a time entry with the date range specified in the form. Note
that the server will initialise the start time with the time of the 
previous transition or state change and the stop time with the current
time. Pressing OK will result in the task taking the specified transition 
to a new state and status and will be marked in the change log. Pressing 
Cancel will discard the form.<br>
<h2>Toggling Interest</h2>
Any user can toggle their interested status in a task. Pressing the
"Toggle Interest" button will result in the Person corresponding to the
user alternatively being added to and removed from the set of
interested Contactables. Note that a record of the transaction will be
kept in the change log.<br>
</body>
</html>
